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Abstract 


This document describes a mechanism that allows Signaling Compression 
(SigComp) implementations to report precise error information upon 
receipt of a message which cannot be decompressed. This negative 
feedback can be used by the recipient to make fine-grained 
adjustments to the compressed message before retransmitting it, 
allowing for rapid and efficient recovery from error situations. 
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Introduction 
Signaling Compression [1], often called "SigComp", defines a protocol 
for transportation of compressed messages between two network 
elements. One of the key features of SigComp is the ability of the 
sending node to request that the receiving node store state objects 
for later retrieval. 
1. The Problem 


While the "SigComp - Extended Operations" document [2] defines a 
mechanism that allows for confirmation of state creation, operational 
experience with the SigComp protocol has demonstrated that there are 
still several circumstances in which a sender's view of the shared 
state differs from the receiver’s view. A non-exhaustive list 
detailing the circumstances in which such failures may occur is 
below. 
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1.1.1. Compartment Disposal 


In SigComp, stored states are associated with compartments. 
Conceptually, the compartments represent one instance of a remote 
application. These compartments are used to limit the amount of 
state that each remote application is allowed to store. Compartments 
are created upon receipt of a valid SigComp message from a remote 
application. In the current protocol, applications are expected to 
signal when they are finished with a compartment so that it can be 
deleted (by using the S-bit in requested feedback data). 


Unfortunately, expecting the applications to be well-behaved is not 
sufficient to prevent state from piling up. Unexpected client 
failures, reboots, and loss of connectivity can cause compartments to 
become "stuck" and never removed. To prevent this situation, it 
becomes necessary to implement a scheme by which compartments that 
appear disused may eventually be discarded. 


While the preceding facts make such a practice necessary, discarding 

compartments without explicit signaling can have the unfortunate side 
effect that active compartments are sometimes discarded. This leads 

to a different view of state between the server and the client. 


1.1.2. Client Restart 


The prime motivation for SigComp was compression of messages to be 
sent over a radio interface. Consequently, most deployments of 
SigComp will involve a mobile unit as one of the endpoints. Mobile 
terminals are generally not guaranteed to be available for extended 
durations of time. Node restarts (due to, for example, a battery 
running out) will induce situations in which the network-based server 
believes that the client contains several states that are no longer 
actually available. 


1.1.3. Server Failover 


Many applications for which SigComp will be used (e.g., SIP [3]) use 
DNS SRV records for server lookup. One of the important features of 
DNS SRV records is the ability to specify multiple servers from which 
clients will select at random, with probabilities determined by the 
q-value weighting. The reason for defining this behavior for SRV 
records is to allow load distribution through a set of equivalent 
servers, and to permit clients to continue to function even if the 
server with which they are communicating fails. When using protocols 
that use SRV for such distribution, the traffic to a failed server is 
typically sent by the client to an equivalent server that can serve 
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the same purpose. From an application perspective, this new server 
often appears to be the same endpoint as the failed server, and will 
consequently resolve to the same compartment. 


Although SigComp state can be replicated amongst such a cluster of 
servers, maintaining integrity of such states requires a two-phase 
commit process that adds a great deal of complexity to the server and 
can degrade performance significantly. 


1.2. The Solution 


Although SigComp allows returned SigComp parameters to signal that 
all states have been lost (by setting "state_memory_size" to 0 for 
one message in the reverse direction), such an approach provides an 
incomplete solution to the problem. In addition to wiping out an 
entire compartment when only one state is corrupt or missing, this 
approach suffers from the unfortunate behavior that it requires a 
message in the reverse direction that the remote application will 
authorize. Unless a lower-layer security mechanism is employed 
(e.g., TLS), this would typically mean that a compressed 
application-level message in the reverse direction must be sent 
before recovery can occur. In many cases (such as SIP-based mobile 
terminals), these messages won’t be sent often; in others (pure 
client/server deployments), they won’t ever be sent. 


The proposed solution to this problem is a simple Negative 
Acknowledgement (NACK) mechanism which allows the recipient to 
communicate to the sender that a failure has occurred. This NACK 
contains a reason code that communicates the nature of the failure. 
For certain types of failures, the NACK will also contain additional 
details that might be useful in recovering from the failure. 


2. Node Behavior 
The following sections detail the behavior of nodes sending and 


receiving SigComp NACKs. The actual format and values are described 
in Section 3. 


2.1. Normal SigComp Message Transmission 


Although normal in all other respects, SigComp implementations that 

use the NACK mechanism need to calculate and store a SHA-1 hash for 

each SigComp message that they send. This must be stored in such a 

way that, given the SHA-1 hash, the implementation is able to locate 
the compartment with which the sent message was associated. 
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In other words, if someone hands the SHA-1 hash back to the 
compressor, it needs to be able to find the compartment with which it 
was working when it sent the message with that hash. This only 
requires that the compressor knows with which compartment it is 
working when it sends a message (which is always the case), and that 
the SHA-1 hash, when stored, points to that compartment in some way. 


2.2. Receiving a "Bad" SigComp Message 


When a received SigComp message causes a decompression failure, the 
recipient forms and sends a SigComp NACK message. This NACK message 
contains a SHA-1 hash of the received SigComp message that could not 
be decompressed. It also contains the exact reason decompression 
failed, as well as any additional details that might assist the NACK 
recipient to correct any problems. See Section 3 for more 
information about formatting the NACK message and its fields. 


For a connection-oriented transport, such as TCP, the NACK message is 
sent back to the originator of the failed message over that same 
connection. 


For a stream-based transport, such as TCP, the standard SigComp 
delimiter of OxFFFF is used to terminate the NACK message. 


For a connectionless transport, such as UDP, the NACK message is sent 
back to the originator of the failed message at the port and IP 
address from which the message was sent. Note that this may or may 
not be the same port on which the application would typically receive 
messages. To accommodate implementations that use connect() or 
similar constructs, the NACK will be sent from the IP address and 
port to which the uninterpretable message was sent. From a practical 
perspective, this is probably easiest to determine by binding 
listening sockets to a specific interface; however, other mechanisms 
may also be employed. 


The behavior specified above is strictly necessary for any generally 
useful form of a NACK mechanism. In the most general case, when an 
implementation receives a message that it cannot decompress, it has 
exactly three useful pieces of information: (1) the contents of the 
message, (2) an indication of why the message cannot be decoded, and 
(3) the IP address and port from which the message originated. Note 
that none of these contains any indication of where the remote 
application is listening for messages, if it differs from the sending 
port. 
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2.3. Receiving a SigComp NACK 


The first action taken upon receipt of a NACK is an attempt to find 
the message to which the NACK corresponds. This search is performed 
using the 20-byte SHA-1 hash contained in the NACK. Once the 
matching message is located, further operations are performed based 
on the compartment that was associated with the sent message. 


Further behavior of a node upon receiving a SigComp NACK depends on 
whether a reliable or unreliable transport is being used. 


2.3.1. Unreliable Transport 


When SigComp is used over an unreliable transport, the application 
has no reasonable expectation that the transport layer will deliver 
any particular message. It then becomes the application layer's 
responsibility to ensure that data is retransmitted as necessary. In 
these circumstances, the NACK mechanism relies on such behavior to 
ensure delivery of the message, and never performs retransmissions on 
the application's behalf. 


When a NACK is received for a message sent over an unreliable 
transport, the NACK recipient uses the contained information to make 
appropriate adjustments to the compressor associated with the proper 
compartment. The exact nature of these adjustments are specific to 
the compression scheme being used, and will vary from implementation 
to implementation. The only requirement on these adjustments is that 
they must have the effect of compensating for the error that has been 
indicated (e.g., by removing the state that the remote node indicates 
it cannot retrieve). 


In particular, when an unreliable transport is used, the original 
message must not be retransmitted by the SigComp layer upon receipt 
of a NACK. Instead, the next application-initiated transmission of a 
message will take advantage of the adjustments made as a result of 
processing the NACK. 


2.3.2. Reliable Transport 


When a reliable transport is employed, the application makes a basic 
assumption that any message passed down the stack will be 
retransmitted as necessary to ensure that the remote node receives 
it, unless a failure is indicated by the transport layer. Because 
SigComp acts as a shim between the transport-layer and the 
application, it becomes the responsibility of the SigComp 
implementation to ensure that any failure to transmit a message is 
communicated to the application. 
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When a NACK is received for a message sent over a reliable transport, 
the SigComp layer must indicate to the application that an error has 
occurred. In general, the application should react in the same way 
as it does for any other transport layer error, such as a TCP 
connection reset. For most applications, this reaction will 
initially be an attempt to reset and re-establish the connection, and 
re-initiate the failed transaction. The SigComp layer should also 
use the information contained in the NACK to make appropriate 
adjustments to the compressor associated with the proper compartment 
(similar to the adjustments made for unreliable transport). Thus, if 
the compartment is not reset by resetting the TCP connection, the 
next message will take advantage of the adjustments. 


2.4. Detecting Support for NACK 


Detection of support for the NACK mechanism may be beneficial in 
certain circumstances. For example, with the current definition of 
SigComp, acknowledgment of state receipt is required before a sender 
can reference such state. When multiple messages are sent before a 
response is received, the need to wait for such responses can cause 
significant decreases in message compression efficiency. If it is 
known that the receiver supports the NACK mechanism, the sender can 
instead optimistically assume that the state created by a sent 
message has been created, and is allowed to be referenced. If such 
an assumption turns out to be false (due to, for example, packet loss 
or packet reordering), the sender can recover upon receipt of a NACK. 


In order to facilitate such detection, any implementation that will 
send NACK messages upon decompression failure will indicate a SigComp 
version number of 0x02 in its Universal Decompressor Virtual Machine 
(UDVM). The bytecodes sent to such an endpoint can check the version 
number, and send appropriate indication back to their compressor as 
requested feedback. Except for the NACK mechanism described in this 
document, implementations advertising a version of 0x02 behave 
exactly like those advertising a version number of 0x01. 


3. Message Format 


SigComp NACK packets are syntactically valid SigComp messages which 
have been specifically designed to be safely ignored by 
implementations that do not support the NACK mechanism. 


In particular, NACK messages are formatted as the second variant of a 
SigComp message (typically used for code upload) with a "code_len" 
field of zero. The NACK information (message identifier, reason for 
failure, and error details) is encoded in the "remaining SigComp 
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"destination" field is used as a version identifier to indicate which 
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The format of the NACK message and the use of the fields within it 
are shown in Figure 1. 
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gure 1: SigComp NACK Message Format 


is a one-byte value that indicates the nature of the 
failure. The specific codes are given in 


led instruction" is a one-byte field that includes 
the opcode to which the PC was pointing when the failure occurred. 
If failure occurred before the UDVM began executing any code, this 


o 0. 
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o "PC of failed instruction" is a two-byte field containing the 
value of the program counter when failure occurred (i.e., the 
memory address of the failed UDVM instruction). The field is 
encoded with the most significant byte of the PC first (i.e., in 
network or big endian order). If failure occurred before the UDVM 
began executing any code, this field is set to 0. 


o "“SHA-1 Hash of failed message" contains the full 20-byte SHA-1 
hash of the SigComp message that could not be decompressed. This 
information allows the NACK recipient to locate the message that 
failed to decompress so that adjustments to the correct 
compartment can be performed. When performing this hash, the 
entire SigComp message is used, from the header byte (binary 
11111xxx) to the end of the input. Any lower-level protocol 
headers (such as UDP or IP) and message delimiters (the OxFFFF 
that marks message boundaries in stream protocols) are not 
included in the hash. When used over a stream based protocol, any 
OxFFxx escape sequences are un-escaped before performing the hash 
operation. 


o "Error Details" provides additional information that might be 
useful in correcting the problem that caused decompression 


failure. Its meaning is specific to the "Reason Code". See 
Section 3.2 for specific information on what appears in this 
field. 


o "Code_len" is the "code_len" field from a standard SigComp 
message. It is always set to "0" for NACK messages. 


o "Version" gives the version of the NACK mechanism being employed. 
This document defines version 1. 


3.2. Reason Codes 


Note that many of the status codes are more useful in debugging 
interoperability problems than with on-the-fly correction of errors. 
The "STATE_NOT_FOUND" error is a notable exception: it will generally 
cause the NACK recipient to encode future messages so as to not use 
the indicated state. 


Upon receiving the other status messages, an implementation would 
typically be expected either to use a different set of bytecodes or, 
if that is not an option, to send that specific message uncompressed. 
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Error Code Details 
STATE_NOT_FOUND 1 State ID (6 - 20 bytes) 
CYCLES_EXHAUSTED 2 Cycles Per Bit (1 byte) 
USER_REQUESTED 3 
SEGFAULT 4 
TOO_MANY_STATE_REQUESTS 5 
INVALID_STATE_ID_LENGTH 6 
INVALID_STATE_PRIORITY 7 
OUTPUT_OVERF LOW 8 
STACK_UNDERF LOW 9 
BAD_INPUT_BITORDER 10 
DIV_BY_ZERO 11 
SWITCH_VALUE_TOO_HIGH 12 
TOO_MANY_BITS_REQUESTED 13 
INVALID_OPERAND 14 
HUFFMAN_NO_MATCH 15 
MESSAGE_TOO_SHORT 16 
INVALID_CODE_LOCATION 15] 
BYTECODES_TOO_LARGE 18 Memory size (2 bytes) 
INVALID_OPCODE 19 
INVALID_STATE_PROBE 20 
ID_NOT_UNIQUE 21 State ID (6 - 20 bytes) 
MULTILOAD_OVERWRITTEN 22 
STATE_TOO_SHORT 23 State ID (6 - 20 bytes) 
INTERNAL ERROR 24 
FRAMING_ERROR 25 


Only the five errors "STATE_NOT_FOUND", "CYCLES_EXHAUSTED", 
"BYTECODES_TOO_LARGE", "ID _NOT_UNIQUE", and "STATE TOO _SHORT" contain 
details; for all other error codes, the "Error Details" field has 
zero length. 
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Figure 2: SigComp NACK Reason Codes 


STATE_NOT_FOUND 

A state that was referenced cannot be found. The state may have 
been referenced by the UDVM executing a STATE-ACCESS 
instruction; it also may have been referenced by the "partial 
state identifier" field in a SigComp message. The "details" 
field contains the state identifier for the state that could not 
be found. This is also the proper error to return in the case 
that a unique state item was matched but fewer bytes of state ID 
were sent than required by the minimum_access_length. 
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2% CYCLES_EXHAUSTED 
Decompression of the message has taken more cycles than were 
allocated to it. The "details" field contains a one-byte value 
that communicates the number of cycles per bit. The cycles per 
bit is represented as an unsigned 8-bit integer (i.e., not 
encoded). 

3 USER_REQUESTED 
The DECOMPRESSION-FAILURE opcode has been executed. 

A SEGFAULT 
An attempt to read from or write to memory that is outside of 
the UDVM’s memory space has been attempted. 

Dis TOO_MANY_STATE_REQUESTS 
More than four requests to store or delete state objects have 
been requested. 

6. INVALID_STATE_TID_LENGTH 
A state id length less than 6 or greater than 20 has been 
specified. 

Ye INVALID_STATE_PRIORITY 
A state priority of 65535 has been specified when attempting to 
store a state. 

8. OUTPUT_OVERFLOW 
The decompressed message is too large to be decoded by the 
receiving node. 

9 STACK_UNDERF LOW 


An attempt to pop a value off the UDVM stack was made with a 
stack_fill value of 0. 


10. BAD_INPUT_BITORDER 
An INPUT-BITS or INPUT-HUFFMAN instruction was encountered with 
the "input_bit_order" register set to an invalid value (i.e., 
one of the upper 13 bits is set). 


11. DIV_BY_ZERO 
A DIVIDE or REMAINDER opcode was encountered with a divisor of 
0. 


T2% SWITCH_VALUE_TOO_HIGH 
The input to a SWITCH opcode exceeds the number of branches 
defined. 
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13 TOO_MANY_BITS_REQUESTED 
An INPUT-BITS or INPUT-HUFFMAN instruction was encountered that 
attempted to input more than 16 bits. 


14. INVALID_OPERAND 
An operand for an instruction could not be resolved to an 
integer value (e.g., a literal or reference operand beginning 
with 11111111). 


15. HUFFMAN_NO_MATCH 
The input string does not match any of the bitcodes in the 
INPUT-HUFFMAN opcode. 


16. MESSAGE _TOO_SHORT 
When attempting to decode a SigComp message, the recipient 
determined that there were not enough bytes in the message for 
it to be valid. 


Sp INVALID_CODE_LOCATION 
The "code location" field in the SigComp message was set to the 
invalid value of 0. 


18. BYTECODES_TOO_LARGE 
The bytecodes that a SigComp message attempted to upload exceed 
the amount of memory available in the receiving UDVM. The 
details field is a two-byte expression of the 
DECOMPRESSION_MEMORY_SIZE of the receiving UDVM. This value is 
communicated most-significant-byte first. 


194 INVALID_OPCODE 
The UDVM attempted to identify an undefined byte value as an 
instruction. 


20. INVALID_STATE_PROBE 
When attempting to retrieve state, the state _ length operand is 
set to 0 but the state_begin operand is non-zero. 


Ze, ID_NOT_UNIQUE 
A partial state identifier that was used to access state matched 
more than one state item. Note that this error might be 
returned as the result of executing a STATE-ACCESS instruction 
or attempting to locate a unique piece of state as identified by 


the "partial state identifier" in a SigComp message. The 
"details" field contains the partial state identifier that was 
requested. 


22. MULTILOAD_OVERWRITTEN 
A MULTILOAD instruction attempted to overwrite itself. 
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23. STATE_TOO_SHORT 
A STATE-ACCESS instruction has attempted to copy more bytes from 
a state item than the state item actually contains. The 
"details" field contains the partial state identifier that was 
requested. Implementors are cautioned to return only the 
partial state identifier that was requested; if the NACK 
contains any state identifier in addition to what was requested, 
attackers may be able to use that additional information to 
access the state. 


24. INTERNAL_ERROR 
The UDVM encountered an unexpected condition that prevented it 
from decompressing the message. 


25. FRAMING_ERROR 
The UDVM encountered a framing error (unquoted OxFF 80 .. OxFF 
FE in an input stream.) This error is applicable only to 
messages received on a stream transport. In the case of a 
framing error, a SHA-1 hash for a unique message Cannot be 
determined. Consequently, when a FRAMING_ERROR NACK is sent, 
the "SHA-1 Hash of failed message" field should be set to all 
zeros. 


4. Security Considerations 
4.1. Reflector Attacks 


Because SigComp NACK messages are by necessity sent in response to 
other messages, it is possible to trigger them by intentionally 
sending malformed messages to a SigComp implementation with a spoofed 
IP address. However, because such actions can only generate one 
message for each message sent, they don’t serve as amplifier attacks. 
Further, due to the reasonably small size of NACK packets, there 
cannot be a significant increase in the size of the packet generated. 


It is worth noting that nearly all deployed protocols exhibit this 
same behavior. 


4.2. NACK Spoofing 


Although it is possible to forge NACK messages as if they were 
generated by a different node, the damage that can be caused is 
minimal. Reporting a loss of state will typically result in nothing 
more than the re-transmission of that state in a subsequent message. 
Other failure codes would result in the next message being sent using 
an alternate compression mechanism, or possibly uncompressed. 
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Although all of the above consequences result in slightly larger 
messages, none of them have particularly catastrophic implications 
for security. 

5. IANA Considerations 


This document defines a new value for the IANA registered attribute 
SigComp_version. 


Value (in hex): 02 
Description: SigComp version 2 (NACK support) 
Reference: [RFC4077] 
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